home *** CD-ROM | disk | FTP | other *** search
/ HPAVC / HPAVC CD-ROM.iso / IPTUT002.ZIP / iptut002.txt < prev   
Text File  |  1995-06-12  |  8KB  |  203 lines
  1. ************************************************************************
  2. * Jouni Miettunen * jon@stekt.oulu.fi * Oulu * Finland * Europe * 1995 *
  3.  
  4.         Intermediate Programmer Tutorial #002
  5.         Copyright (c) 1995 by Jouni Miettunen
  6.               Version 1.2 - 12 June 1995
  7.  
  8.         Turbo C++ 3.0 Bugs and How to Deal with Them
  9.  
  10. ** INTRODUCTION
  11.  
  12. I code small DOS applications, usually with my own GUI library. None of
  13. the programs need to be realtime, handle multiple huge datafiles or do
  14. several things at the same time. Still they need to function correctly.
  15.  
  16. The purpose of this tutorial is to collect information about TC3 bugs,
  17. peculiar or annoying features and how to cope with them. If you have
  18. some more information, please contact me and I'll update this document.
  19. I have already released one buggy program, when I couldn't make the
  20. final "clean" compilation thanx to constant compiler crashes. I'm sure
  21. the tone of this document will reveal you what I think about such a
  22. product and a company.
  23.  
  24. ** THE GOOD, THE BAD AND TURBO C++ 3.0
  25.  
  26. My Chosen Compiler (TM) is TC3 and I am not too happy with it. When I
  27. have afford, I'll buy Watcom C/C++ compiler.. in case I'll continue
  28. writing DOS programs.
  29.  
  30. The bad points are that Borland doesn't support TC3 anymore and that it
  31. is buggy. On the other hand this is quite understandable remembering it
  32. was released 1992 and is a DOS program. The manual isn't quite adequate
  33. even as an elbow rest and the online Reference Guide doesn't fill my
  34. needs.
  35.  
  36. The good points are that it was reasonably inexpensive, is reasonably
  37. fast, generates reasonably tight code and usually works just fine. The
  38. most important feature is IDE (Integrated Development Environment ie. a
  39. Text User Interface) to help developing, debugging, compiling and
  40. linking programs in the same nice visual environment. Code hilighting is
  41. a feature I've found very useful.
  42.  
  43. You also has to remember that TC3 is an ANSI C compiler, supports the
  44. basic features of C++ and comes with a royalty free full graphics
  45. library (BGI). The money I spent buying it was not wasted, I just
  46. thought I'd get a perfect program. Instead I got a rude awakening..
  47.  
  48. ** WINERROR 3
  49.  
  50. TC3 supports several screen resolutions (24/43/50 lines) and thus has
  51. some internal information about the locations of its windows. Sometimes
  52. this info gets corrupted and fools TC3 to try to open windows or dialogs
  53. outside the visible screen area. The result is compiler crash. If you
  54. get lucky, only the compiler will crash (winerror = 3) and you can try
  55. again, but occasionally also the whole system crashes needing a reboot.
  56.  
  57. The solution is to every now and then close all open windows and reopen
  58. those you need. This is done by selecting Window menu and there item
  59. Close All. Another possibility is to delete the desktop file (*.dsk)
  60. before starting TC3.
  61.  
  62. Window:Close All - just select this once
  63.  
  64. ** NOT ENOUGH MEMORY TO START
  65.  
  66. If you use IDE, but don't have enough memory to load datafiles or even
  67. start the program, disable Debugger. Also remember to disable the two
  68. related debugging options.
  69.  
  70. Options:Compiler:Advanced Code Generation:Line Numbers Debug Info - OFF
  71. Options:Compiler:Advanced Code Generation:Debug Info In OBJs - OFF
  72. Options:Debugger:Source Debugging - OFF
  73.  
  74. ** NOT ENOUGH MEMORY TO DEBUG
  75.  
  76. Sometimes you would like to debug your program with the build-in
  77. debugger, but can't, since there's not enough free memory.. or that's
  78. what TC3 thinks.
  79.  
  80. By default only 64K is reserved for your program's dynamically allocated
  81. data. Fortunately you can increase this value by yourself and debug the
  82. program just fine. Still you have to remember that there is a real limit
  83. in the amount of available memory that can't be changed by any compiler
  84. options.
  85.  
  86. Options:Debugger:Program Heap Size - write a new value
  87.  
  88. I'd recommend using values under 640K, the amount of conventional DOS
  89. memory. If you need more, don't use TC3.
  90.  
  91. ** BUILT-IN ASSEMBLER
  92.  
  93. Turbo C comes with a built-in assembler. The manual index says to see
  94. "The online document" mentioning filename UTIL.DOC, but the correct file
  95. is BASM.DOC.
  96.  
  97. There are few things to remember about BASM syntax: labels have to be
  98. outside asm {} block and the comments have to be C or C++ comments.
  99.  
  100. SkipScanLine:
  101.  
  102. waitHRTend:
  103. asm {
  104.     in    al,dx
  105.     test    al,01h
  106.     jz    waitHRTend
  107. }
  108. waitHRTstart:
  109. asm {
  110.     in    al,dx
  111.     test    al,01h
  112.     jnz    waitHRTstart
  113.  
  114.     loop    short SkipScanLine /* wait till cx scan lines passed */
  115. }
  116.  
  117. The inline assembler is a 16-bit assembler and supports only 8086 code
  118. generation. However placing the 66h "operand size override" on the line
  119. before the instruction can force it to be understood as 32-bit.
  120.  
  121. asm db 0x66
  122. asm rep stosw    // rep stosd
  123.  
  124. ** 64K LIMIT
  125.  
  126. The most frustrating thing in DOS programming is the memory management
  127. and especially the long and hard cursed 64k limitation in.. everything!
  128.  
  129. If you read a file into a buffer, you can read only the first 64k. If
  130. you print a text string, you can print only the first 64k.
  131.  
  132. The solution seems to be using huge pointers, as suggested in various
  133. referencies. The problem is that huge pointers are really slow.. but the
  134. problem might be the solution, if you know what you're doing: using huge
  135. pointers mean in practice that you use far pointers that are normalized
  136. everytime their value is changed. You can do this yourself, if you can
  137. identify the moments, when it is necessary.
  138.  
  139. ** INCREMENTING POINTERS
  140.  
  141. There is something strange in the pointer incrementation.. According to
  142. the ANSI C specification, which TC3 is supposed to obey, the following
  143. code examples should do exactly the same thing: add 2 into the value of
  144. the variable.
  145.  
  146.     char far    *ch;
  147.  
  148.     ch += 2;
  149.     ch = ch + 2;
  150.  
  151. However TC3 generates different code for them:
  152.  
  153.    ;    
  154.    ;    ch += 2;
  155.    ;    
  156.     add    word ptr [bp-4],2
  157.    ;    
  158.    ;    ch = ch + 2;
  159.    ;    
  160.     mov    ax,word ptr [bp-2]
  161.     mov    dx,word ptr [bp-4]
  162.     add    dx,2
  163.     mov    word ptr [bp-2],ax
  164.     mov    word ptr [bp-4],dx
  165.  
  166. At first sight this might seem ok: both add the requested value into the
  167. offset of the variable (and offset wraps around). The first example even
  168. might seem to be a better choice, since it generates less "unused" code.
  169. However in practise I've found the second way to be more reliable..
  170. Occasionally the first one just doesn't seem to be doing what the code
  171. says it to do, especially when incrementing char far *pointers.
  172.  
  173. Since I don't have any real asm manual, I can't tell at the moment what
  174. is the difference in operation. First one is an indirect addition and
  175. the second one is a direct addition with a register. Should RTFM a bit..
  176.  
  177. ** HISTORY
  178.  
  179. 1.0    Winerror 3, Not enough memory to start
  180. 1.1    BASM, Pointer normalization
  181. 1.2    Not enough memory to debug, Pointer incrementation
  182.  
  183. ** DISCLAIMER
  184.  
  185. Please note I have written this tutorial in good faith, but I cannot
  186. guarantees its contents. I think it's all correct, that things really
  187. work this way and could be taken care of like this. If something goes
  188. wrong, that will be your problem, not mine. You have been warned.
  189.  
  190. Additions, fixes and spelling and grammar instructions are most welcome.
  191. Hope you could find this useful. This tutorial is copyrighted, but
  192. freely redistributable material.
  193.  
  194. ** AUTHOR
  195.  
  196.     Mr. Jouni Miettunen
  197.     Rautatienkatu 20 A 10
  198.     FIN-90100 OULU
  199.     FINLAND - EUROPE
  200.  
  201. * Jouni Miettunen * jon@stekt.oulu.fi * Oulu * Finland * Europe * 1995 *
  202. ************************************************************************
  203.